Graphical user interfaces have become standard fare on most computers sold today. For example, versions of the MICROSOFT WINDOWS operating system provide a graphical user interface in which a pointer is positionable over windows on a screen via an input device such as a mouse or a trackball. Clicking a button on the input device when the pointer is positioned over a given feature of the window, such as a control, registers with the program hosting the window, such that the program performs a given functionality associated with the control. For example, moving the pointer over a “save” button in a window hosted by a word processing program, and clicking a button on the application programs in the MICROSOFT WINDOWS operating system. ACTIVEX controls are known within the art, and are described in Adam Denning, ActiveX Controls Inside Out (ISBN 1-57231-350-1) (1997), and David Chappell, Understanding ActiveX and OLE (ISBN 1-57231-216-5) (1996), both of which are hereby incorporated by reference. For example, in the Chappell book, on page 205, is states that qualifying as an ActiveX control (OLE Controls technology was renamed ActiveX Controls) requires only support for the IUnknown interface and the ability to self-register with the system registry. Using ACTIVEX controls that have already been created means that computer programmers do not have to “reinvent the wheel”—that is, they do not have to create controls that have been already created by others.
However, for many programmers normally accustomed to only the WIN32 API, using ACTIVEX controls in MICROSOFT WINDOWS operating system-intended programs is not straightforward. A programmer may, for example, have to write original “container code,” so that the ACTIVEX control may be hosted within a window via the container code. Again, many programmers may not be experienced in creation of such container code. Furthermore, hosting ACTIVEX controls within application program windows may require the programmer to have experience in Component Object Model (COM) objects, which the programmer may not have. COM is known within the art, and is described in Dale Rogerson, Inside COM (ISBN 1-57231-349-8) (1997), which is hereby incorporated by reference. Thus, even if having access to a large number of ACTIVEX controls, a programmer may still not be able to easily include them in a given computer program under development.
A limited solution to this problem is provided by the Microsoft Foundation Classes (MFC). ACTIVEX controls may be accessible through MFC for programmers who use the computer language C++ to develop computer programs. a significant disadvantage is presented to those programmers who do not utilize C++ to develop programs. That is, because MFC is typically not accessible except through C++, a computer programmer without such knowledge may find himself or herself still unable to utilize existing ACTIVEX user interface controls within computer programs the Again, however, programmer may be developing.
There is a need, therefore, for permitting computer programmers to include ACTIVEX controls in their programs in an easy-to-understand and straightforward fashion. That is, there is a need for permitting computer programmers to include ACTIVEX controls in their programs without having to resort to COM, or MFC (via C++). Ideally, a programmer should be able to include ACTIVEX controls in a computer program using precepts and constructs already familiar to him or her.